4. Upgrading Message Connectivity From Exchange Server 2003
This section will cover the
issues and best practices surrounding upgrading your messaging
connectivity to Exchange Server 2010, including internal and external
message routing.
4.1. Internal Message Routing
You'll find significant
differences in message routing between Exchange Server 2003 and
Exchange Server 2010. This section describes these changes and outlines
the actions necessary to ensure successful coexistence.
|
Markus Bellmann
Senior Solutions Architect, Siemens, Germany
When deploying Exchange
Server 2010 into an Exchange Server 2003 environment with multiple
routing groups, I've found that it's best to configure additional
routing group connectors between Exchange Server 2003 and Exchange
Server 2010. These additional connectors can optimize your message flow
for remote routing groups so that messages between user mailboxes
upgraded to Exchange Server 2007 and those still on Exchange Server 2003
don't go across the WAN links. Additional connectors can also provide
redundancy so that message routing between Exchange Server 2003 and
Exchange Server 2010 does not have a single point of failure.
|
In an Exchange Server 2003
environment consisting of multiple routing groups, it is best practice
to create additional routing group connectors to optimize message routing and
provide redundancy between Exchange Server 2003 routing groups and
Exchange Server 2010. These connectors are created using the New-RoutingGroupConnector
cmdlet in the Exchange Management Shell (EMS) and not the Exchange
System Manager in Exchange Server 2003. In this way, the membership of
the ExchangeLegacyInterop universal
security group is then automatically updated with the Exchange Server
2003 servers specified so they have the necessary permissions to send
and receive mail from the Exchange Server 2010 Hub Transport servers.
An example of creating a new
routing group connector is shown here, where the Exchange Server 2010
source transport server is Seattle-EX10.contoso.com, the Exchange Server
2003 bridgehead server is Seattle-EX03.contoso.com, and the routing
group connector is a two-way connector with a cost of 100:
New-RoutingGroupConnector -Name "Interop RGC" -SourceTransportServers "Seattle-EX10.
contoso.com" -TargetTransportServers "Seattle-EX03.contoso.com" -Cost 100
-Bidirectional $true
4.2. Exchange Server 2010 Send and Receive Connectors
The Hub Transport server
role provides SMTP transport for an Exchange Server 2010 infrastructure.
Unlike Exchange Server 2003, where messaging connectivity between
locations is provided by routing-group connectors, the Hub Transport
role routes messages between Active Directory sites using an inherent connector called the intra-organization Send connector. Additionally, during the Hub Transport server role installation two explicit Receive
connectors are created. SMTP traffic from all sources on port 25 is
received by the first connector, whereas SMTP traffic from non-MAPI
clients is received on port 587 by the second Receive connector.
4.3. External Message Routing
In some environments,
the Exchange Server 2010 Edge Transport role is not deployed and
Internet mail is either received directly on the Hub Transport servers
or a third-party SMTP smart host is deployed in the perimeter network.
Both of the default Exchange Server 2010 Hub Transport Receive
connectors (outlined in the Section 4.2
section of this article) require authentication by default, so to allow
for this scenario the receive connector accepting SMTP connections from
the Internet or the smart host must be configured to allow anonymous
access to accept SMTP messages from the Internet.
To route messages to the
Internet, a Send connector must be configured. In an upgrade where the
Exchange Server 2010 Edge Transport server role is deployed in a
perimeter network to route messages to remote domains, when the Edge
Transport server is subscribed to the Exchange organization the
necessary connectors are created automatically. However, if the Exchange
Server 2010 Hub Transport servers will be sending SMTP traffic
directly, or a third-party SMTP smart host is deployed in the perimeter
network, you will need to manually create and configure Send connectors.
You can manually create and configure Send connectors either through the Exchange Management Console or using Windows PowerShell via the EMS. The following is an EMS example of creating an Internet send
connector with a cost of 10, where the source Hub Transport server is
Seattle-EX10 and all outbound SMTP is routed via a smart host named
smtp.contoso.com:
New-SendConnector -Name 'Internet Outbound' -Usage 'Custom' -AddressSpaces
'SMTP:*;10' -IsScopedConnector $false -DNSRoutingEnabled $false -SmartHosts
'smtp.contoso.com' -SmartHostAuthMechanism 'None' -UseExternalDNSServersEnabled $false
-SourceTransportServers 'Seattle-EX10'
